Objetivo
Simular la interacción básica de partículas con ciertos medios gracias al software Geant4, desarrollado por el CERN.
Play with Docker es un servicio cloud que nos permite jugar con Docker sin necesidad de instalar Docker localmente. Cada vez que accedemos a una sesión en Play with Docker, tenemos 4 maravillosas horas para experimentar con Docker, hasta que esta se cierra automáticamente. Parece poco tiempo pero es el suficiente para llevar a cabo nuestro humilde y divertido laboratorio. Dicho de otra manera: tenemos acceso casi ilimitado (en recursos) a un super computador orientado a familiarizarnos con contenedores virtuales durante todo el periodo de duración de la clase/laboratorio. Para acceder a Play with Docker, sólo necesitamos una cuenta en Docker. Como en la gran mayoría de servicios, este registro es gratuito, rápido y comporta los típicos pasos de selección de contraseña, envío de correo, confirmación de recepción de correo, etc.
Una vez que ya tenemos acceso a la consola de Play with Docker, podemos solicitar máquinas reales (en realidad siguen siendo virtuales, pero a efectos prácticos, las trataremos como si fueran reales) sobre las que ejecutar a su vez contenedores Docker gracias a su toolkit. Al inicio no habrá ninguna, pero podemos crear la primera (y única que necesitamos) con el comando ADD NEW INSTANCE que se puede ver en la imagen.
Cuando creamos una instancia, es como si accediéramos a una máquina pseudo real (o para lo que a todos los efectos, será una máquina real para nosotros). Se nos abrirá una sesión de shell de GNU Linux (Bash en este caso) justo al lado y sobre la que podemos introducir comandos Unix de toda la vida, entre ellos los relacionados con Docker. En estas máquinas cuasi-reales ya está instalado todo el stack de Docker y podemos, a su vez, trabajar con contenedores virtuales basados en esta tecnología de vanguardia. En realidad Play with Docker hace uso de DIND. Esta tecnología permite albergar contenedores Docker dentro de un contenedor Docker (sí, algo así como un sueño dentro de un sueño). Es decir: las instancias en Play with Docker son en realidad… ¡contenedores Docker!
Una máquina virtual es una visualización de un equipo físico completo. Se emula por software todos sus componentes, tanto físicos como lógico. Esto incluye los discos duros, tarjeta de red, gráfica, sonido, etc. Además del SO con su kernel y todos sus servicios.
Fíjate que la instancia que has creado en Play with Docker es como si se tratara de un ordenador tuyo que estuviera en red y en ese ordenador tuvieras instalado Docker. Así de sencillo. A partir de ese momento ya no necesitamos acceder a Play with Docker mediante en el navegador (aunque está bien que lo dejes aparcado a un lado en caso de necesidad). Usaremos VS Code y acceso SSH tradicional, concretamente mediante dos clientes SSH milenarios: OpenSSH y Putty. El primero viene preinstalado típicamente en máquinas GNU/Linux y macOS y el segundo se tiene que descargar y hay versiones para todos los sistemas operativos (es el que se recomienda, por simplicidad, si estás en Windows). Este enunciado viene preparado para uses cualquiera de los dos, en cualquier sistema.
Importante: tómate nota del usuario que te da Play with Docker y que empieza por ip y acaba en @direct… (Ejemplo: ip172-18-0-27-bg3pvjs3uhdg008ir0fg). Copia esa cadena de texto y guárdatela para futuros usos. A lo largo de este trabajo nos referiremos a ella con la variable de entorno $usuariopwd. También puedes regenerar el contenido de esta variable mediante este comando (a ejecutar en la consola web de Play with Docker):
echo ip$(ifconfig eth1 | grep "inet " | awk -F'[: ]+' '{ print $4 }' | sed 's/\./-/g')-$SESSION_ID
Ejecuta el comando
echoque imprime por la salida estándar el texto que le siga, expandiendo el contenido de las variables. En nuestro caso tenemos dos variables, una de ellas implícita. El formato que tenemos es esteecho ip$var1-$var2. Donde$var1representa el resultado de la expresión contenida entre paréntesis y$var2representa el contenido de la variable$SESSION_ID, que no es otro que el identificador de sesión que nos ha asignadoPlay whit Docker.Para lo que sería
$var1, dentro del paréntesis se ejecuta el comandoifconfig eth1y su salida la pasa al comandogrep "inet "usando una tubería (pipe), este pasa su salida aawk -F'[: ]+' '{ print $4 }'y este ased 's/\./-/g'.
ifconfig: El comando
ifconfigmuestra las propiedades de las interfaces de red instaladas en el equipo. El argumentoeth1filtra la salida para que solo devuelva las propiedades de la interfaz de red con ese nombre.Ejemplo de salida del comando
ifconfig eth0Nótese que he cambiado el argumento
eth1poreth0, puesto que mi maquina no dispone de una interfaz de red con el nombreeth1.grep: El comando
grepbusca un fragmento de texto y filtra cualquier contenido entre retornos de carro, y/o cambios de línea, que no contengan el fragmento de texto pasado como argumento. En nuestro caso todas las líneas que devuelva el comandoifconfig eth0que no contengan la cadena de caracteres"inet "incluyendo el espacio. Para nuestro ejemplo el comandoifconfig eth0 | grep "inet "devolvería lo siguiente:Como se ve, se han eliminado todas las líneas que no contenían el texto
"inet "awk: El comando
awkal igual quegrepbusca un fragmento de texto, pero este puede filtrar el contenido de cada línea. En nuestro caso se establece el modo de funcionar usando varios argumentos. Enawk -F'[: ]+' '{ print $4 }',-F'[: ]+'establece la secuencia de caracteres que se usará como separador de campos,-Findica que se va a establecer un separador de campos especifico. Lo que le sigue es una expresión regular, o regex, con la que desea que coincida el texto que hará de separador de campos. Concretamente-F'[: ]+'establece como separador de campos cualquier secuencia que este compuesta de uno o más caracteres de los contenidos entre los corchetes, estos son los dos puntos ':' y el espacio. Todos estos ejemplos coincidirían con ese regex' :: ',' ','::::::::'. La parte'{ print $4 }'expresa como formatear la salida, en este ejemplo se establece que se imprima el cuarto campo, es decir el contenido entre la tercera y la cuarta coincidencia del regex.En mi ejemplo nos encontramos un problema, este es que el comando anterior devuelve la línea con espacios antes de la cadena
"inet ", por lo que el primer campo corresponde al contenido antes de la primera coincidencia del regex, que evidentemente es una cadena vacía''. Esto provoca que no se devuelva lo que se espera, si no que devuelvenetmask.Para conseguir que se devuelva mi mascara de red se debería de usar
awk -F'[: ]+' '{ print $5 }':Pero intuyo que lo que se desea es mi dirección IP, para lo cual necesitaremos usar
awk -F'[: ]+' '{ print $3 }'sed: El comando
sedpermite modificar el texto que recibe. En tal como está configurado con's/\./-/g', se le está pidiendo que sustituya cada punto.que encuentre por un guion-.En el ejemplo resultaría:
Con esto tenemos el contenido del paréntesis, a lo que le precede los caracteres 'ip' y le sigue un guion seguido del contenido de la variable
$SESSION_IDque para el enunciado contienebg3pvjs3uhdg008ir0fg. Así que el comandoechomostrará primero la parte explicitaip, seguido de lo del paréntesis172-23-122-172, seguido de un guion-explícito y finalmente la variable $SESSION_IDbg3pvjs3uhdg008ir0fg. Si lo juntamos el resultado es:Como vemos coincide con lo mencionado
ip172-18-0-27-bg3pvjs3uhdg008ir0fg, con la salvedad de que la ip que aparece es la de mi máquina.
Estos son los distintos programas/paquetes que necesitas en tu sistema local:
MSVCP110.dll en el caso de algunas versiones de Windows, instalad el runtime mínimo de Microsoft Visual C++ 2012 Redistributable para 64 bit desde aquí.Sinceramente, hasta antes de esto ninguno, salvo CAD, que en realidad no es un formato estándar, ya que CAD admite diferentes formatos, tanto para 2D como para 3D. Después de esto conozco los aquí mencionados. Collada, Stanford, Wavefront, X3D Extensible, Standard Tessellation Language, x3dom
Instant Player pertenece a 'The instantReality framework'. El proyecto está actualmente coordinado y respaldado por el grupo Fraunhofer IGD / Visual Computing System Technologies.
El Instituto Fraunhofer de Gráficos por Computadora (IGD-VCST) cubre un amplio espectro de experiencias y competencias en los campos de las tecnologías de Realidad Virtual / Aumentada y Computación Visual.
The Visualization Toolkit (VTK) es un sistema de software para gráficos 3D por ordenador, procesamiento de imágenes y visualización. Admite muchos algoritmos de visualización y técnicas de modelado. VTK puede realizar un procesamiento paralelo y puede representar datos científicos en un navegador web . VTK se utiliza en todo el mundo en aplicaciones comerciales, así como en investigación y desarrollo. Las aplicaciones que usan VTK incluyen Molekel, ParaView, VisIt, VisTrails, MOOSE, 3D Slicer, MayaVi y OsiriX. VTK está escrito en C ++ y está empaquetado para acceder a través de Python, Java y Tcl. ActiViz proporciona soporte para VTK en proyectos .Net / C #.
ParaView crea visualizaciones científicas interactivas para analizar datos utilizando técnicas cualitativas y cuantitativas. Tiene una arquitectura cliente-servidor para facilitar la visualización remota de conjuntos de datos y genera modelos de nivel de detalle (LOD) para mantener velocidades de cuadro interactivas para grandes conjuntos de datos. Está diseñado para el paralelismo de datos en multicomputadoras y clústeres de memoria compartida o memoria distribuida. También se puede ejecutar como una aplicación para una sola computadora.
CMake es una herramienta de compilación multiplataforma para controlar el proceso de compilación de software utilizando archivos de configuración simples independientes de la plataforma y del compilador. CMake genera archivos MAKE y espacios de trabajo nativos que se pueden usar en el compilador de su elección.
The Insight Toolkit (ITK) Es una biblioteca de algoritmos de segmentación y registro de imágenes adaptados para investigaciones médicas.
El kit de herramientas es compatible con una variedad de formatos de datos de imágenes, que incluyen imágenes digitales y comunicaciones en medicina (DICOM), MRI, CT y ultrasonido. Además, presenta un proceso de empaquetado automatizado para generar interfaces entre C++ y lenguajes de programación interpretados como Python o JavaScript, para permitir a los desarrolladores crear software usando una gran variedad de lenguajes de programación. Tiene una estructura modular flexible que es fácil de ampliar e integrar en varios proyectos.
3D Slicer es una aplicación de código abierto extensible para visualización y análisis de imágenes médicas. 3D Slicer funciona con imágenes ópticas, resonancia magnética, tomografía computarizada y datos de ultrasonido. Se ha utilizado para aplicaciones comerciales y de investigación que van desde estudios preclínicos en animales, hasta planificación y orientación quirúrgica, análisis de imágenes de ultrasonido, control de robots médicos y estudios de población.
3D Slicer utiliza VTK e ITK: VTK para sus procesos de renderizado 2D y 3D, transformación lineal y no lineal, infraestructura de segmentación, procesamiento de malla e integración de realidad virtual e ITK para el procesamiento de imágenes más lectura y escritura de imágenes.
VIAME es una plataforma de software de visión por computadora de código abierto diseñada para la inteligencia artificial (IA) do-it-yourself (hazlo tú mismo). Es un conjunto de herramientas en evolución que contiene muchos flujos de trabajo que se utilizan para generar diferentes detectores de objetos, clasificadores de fotograma completo, mosaicos de imágenes, generación rápida de modelos, búsqueda de imágenes y videos y métodos de medición estéreo.
Originalmente dirigido al análisis de especies marinas, ahora contiene muchos algoritmos y bibliotecas comunes, y también es útil como una biblioteca genérica de visión por computadora fuera de las imágenes y videos submarinos. VIAME está disponible como aplicación web o de escritorio.
TeleSculptor es una aplicación de escritorio de usuario final de código abierto para fotogrametría aérea. Aprovecha los algoritmos de KWIVER para construir modelos de escenas en 3D a partir de videos aéreos, como videos recopilados de UAV. Maneja coordenadas geoespaciales y puede hacer uso de metadatos, si están disponibles, de sensores GPS e IMU. Sin embargo, también puede funcionar con datos no geoespaciales y con colecciones de imágenes sin metadatos asociados. Aunque es principalmente una aplicación de usuario final, es altamente reconfigurable para soportar también la investigación y el desarrollo de fotogrametría.
Girder es una plataforma de gestión de datos basada en web gratuita y de código abierto que forma parte del ecosistema de análisis y datos de Resonant. Puede usarse como una aplicación independiente o una plataforma para crear nuevos servicios web. Permite la construcción rápida y sencilla de aplicaciones web que tienen algunos o todos los siguientes requisitos: organización y difusión de datos, gestión y autenticación de usuarios, gestión de autorizaciones.
Un software de contenerización.
La idea detrás de Docker es crear contenedores ligeros y portables para las aplicaciones software que puedan ejecutarse en cualquier máquina con Docker instalado, independientemente del sistema operativo que la máquina tenga por debajo, facilitando así también los despliegues. Es un entorno de virtualización ligero que te permite construir y ejecutar aplicaciones dentro de un contenedor de software aislado. No se apoya en un hypervisor como la virtualización tradicional, se puede considerar una aplicación dentro del servidor.
Algunas de las alternativas que podemos encontrar son:
- RKT.
- PodMan.
- Singularity.
- Linux Containers – LXC.
- OpenVz.
Docker nace como un sistema enfocado a Plataforma como Servicio, o, PaaS de sus siglas en ingles Platform as a Service). Solomon Hykes, junto con otros ingenieros como Andrea Luzzardi, Francois-Xavier Bourlet y Jeff Lindsay, comenzó Docker como un proyecto interno dentro de la empresa dotCloud.
Docker fue liberado en marzo de 2013 convirtiéndose en un software de código abierto.
En el 2014 remplazó su entorno de ejecución por defecto por su propia biblioteca, libcontainer, escrita en Go.
En abril de 2015, el proyecto tenía más de 20.700 estrellas de GitHub (Posicionándolo en el puesto 20ª del rancking de proyectos con más estrellas de GitHub), más de 4.700 bifurcaciones (forks), y casi 900 colaboradores.
En 2018 un estudio mostró que organizaciones como Red Hat, Microsoft, IBM, Google, Cisco Systems y Amadeus IT Group, aportaban mayores contribuciones al proyecto que el propio equipo de Docker, siendo Red Hat la organización más volcada con el proyecto.
La realización de este actividad se ha realizado ejecutando la simulación en un contenedor Docker en local, cortesía del Dr. Alberto Corbi.
.key y .ppk que contienen las claves que se utilizan en una comunicación encriptada con cifrado de clave pública. Por lo que no necesitamos crear una instancia en Play with Docker.geant4lab.ppk y geant4lab.key desde aquí.Como he comentado más arriba estos archivos contienen las claves necesarias para encriptar y desencriptar la información que se envía y se recibe. Concretamente ppk contiene la clave privada y su nombre viene de PuTTY Private Key.
Es el equivalente al ppk pero para usarlo en SSH en vez de PuTTY
Lo primero que tenemos que hacer es descargarnos la imagen de la pila de contenedores que conforman una imagen con todo lo necesario para ejecutar Geant4. Esta imagen se encuentra ya en el Docker Hub.
Docker Hub es un servicio proporcionado por Docker para encontrar y compartir imágenes de contenedores en nuestros ordenadores.
Una imagen es una plantilla para construir un contenedor. Una imagen nunca cambia. Un contenedor es una instancia de una imagen. Se pueden construir los contenedores que se quiera partiendo de la misma imagen.
Para descargar la imagen Docker con la que ejecutaremos la simulación, enviaremos el comando (docker pull) desde nuestra máquina local y esperamos a que se descargue.
Este comando Docker (docker pull) lo que hace es descargarse la imagen geant4lab del usuario pammacdotnet alojada en el Hub de Docker. La descarga se produce desde este Hub al disco de nuestra máquina local.
$ docker pull pammacdotnet/geant4lab
Using default tag: latest
latest: Pulling from pammacdotnet/geant4lab
32802c0cfa4d: Pulling fs layer
da1315cffa03: Pulling fs layer
fa83472a3562: Pulling fs layer
f85999a86bef: Pulling fs layer
4adeade91205: Pulling fs layer
a8e4b753ce11: Pulling fs layer
e9f91fadad2e: Pulling fs layer
05bd8563d519: Pulling fs layer
17dea6add1aa: Pulling fs layer
ffc09338d88e: Pulling fs layer
c7061889ec78: Pulling fs layer
82cf27079d06: Pull complete
3fd0b7114b4d: Pull complete
762fc1ce02fe: Pull complete
e29f76d111d5: Pull complete
10d5c3407cc3: Pull complete
cacafc401cf0: Pull complete
2e5ea4f36bbd: Pull complete
9a46be81e6b4: Pull complete
dd1b29d9ca12: Pull complete
b3d7bb7e2722: Pull complete
485e80a4790d: Pull complete
Digest: sha256:7b342489eda508f6bf3d9723437c1107219c2f46ab24d0072f6341d00d486446
Status: Downloaded newer image for pammacdotnet/geant4lab:latest
docker.io/pammacdotnet/geant4lab:latest
Desde la consola de Bash integrada en VS Code descargamos el fichero simulation.py.
curl https://raw.githubusercontent.com/pammacdotnet/FFRepo/master/simulation.py -o simulation.py -s
De igual manera, descargamos el fichero wrl2html.py, que servirá más tarde para generar versiones WebGL de las simulaciones:
curl https://raw.githubusercontent.com/pammacdotnet/FFRepo/master/wrl2html.py -o wrl2html.py -s
chmod +x wrl2html.py
Este código de la simulación describe un experimento de física de partículas cuya representación es más o menos esta:
Se trata de un universo en forma de cuboide donde las partículas subatómicas son aceleradas (por los medios que sean) y son proyectadas con forma cónica contra un objetivo (un target o fantoma) de un material que podemos variar a nuestro antojo en composición, tamaño y posición. Nosotros no nos preocupamos sobre cómo esas partículas han cobrado esa energía, sino solamente por cómo interaccionan con la materia.
Pencil beam
Ahora sólo tenemos que lanzar el comando de ejecución de la simulación (con opciones por defecto) desde el terminal integrado de VS Code:
$ docker run -v ${PWD}:/root pammacdotnet/g4lpwd
**************************************************************
Geant4 version Name: geant4-10-04-patch-02 (25-May-2018)
Copyright : Geant4 Collaboration
References : NIM A 506 (2003), 250-303
: IEEE-TNS 53 (2006), 270-278
: NIM A 835 (2016), 186-225
WWW : http://geant4.org/
**************************************************************
Visualization Manager instantiating with verbosity "warnings (3)"...
/tracking/storeTrajectory 1
/tracking/storeTrajectory 2
phot: for gamma SubType= 12 BuildTable= 0
LambdaPrime table from 200 keV to 100 TeV in 61 bins
===== EM models for the G4Region DefaultRegionForTheWorld ======
PhotoElectric : Emin= 0 eV Emax= 100 TeV AngularGenSauterGavrila
compt: for gamma SubType= 13 BuildTable= 1
Lambda table from 100 eV to 1 MeV, 7 bins per decade, spline: 1
LambdaPrime table from 1 MeV to 100 TeV in 56 bins
===== EM models for the G4Region DefaultRegionForTheWorld ======
Klein-Nishina : Emin= 0 eV Emax= 100 TeV
conv: for gamma SubType= 14 BuildTable= 1
Lambda table from 1.022 MeV to 100 TeV, 18 bins per decade, spline: 1
===== EM models for the G4Region DefaultRegionForTheWorld ======
BetheHeitler : Emin= 0 eV Emax= 80 GeV
BetheHeitlerLPM : Emin= 80 GeV Emax= 100 TeV
msc: for e- SubType= 10
RangeFactor= 0.04, stepLimitType: 1, latDisplacement: 1
===== EM models for the G4Region DefaultRegionForTheWorld ======
UrbanMsc : Emin= 0 eV Emax= 100 TeV Table with 84 bins Emin= 100 eV Emax= 100 TeV
eIoni: for e- SubType= 2
dE/dx and range tables from 100 eV to 100 TeV in 84 bins
Lambda tables from threshold to 100 TeV, 7 bins per decade, spline: 1
finalRange(mm)= 1, dRoverRange= 0.2, integral: 1, fluct: 1, linLossLimit= 0.01
===== EM models for the G4Region DefaultRegionForTheWorld ======
MollerBhabha : Emin= 0 eV Emax= 100 TeV
eBrem: for e- SubType= 3
dE/dx and range tables from 100 eV to 100 TeV in 84 bins
Lambda tables from threshold to 100 TeV, 7 bins per decade, spline: 1
LPM flag: 1 for E > 1 GeV, VertexHighEnergyTh(GeV)= 100000
===== EM models for the G4Region DefaultRegionForTheWorld ======
eBremSB : Emin= 0 eV Emax= 1 GeV DipBustGen
eBremLPM : Emin= 1 GeV Emax= 100 TeV DipBustGen
msc: for e+ SubType= 10
RangeFactor= 0.04, stepLimitType: 1, latDisplacement: 1
===== EM models for the G4Region DefaultRegionForTheWorld ======
UrbanMsc : Emin= 0 eV Emax= 100 TeV Table with 84 bins Emin= 100 eV Emax= 100 TeV
eIoni: for e+ SubType= 2
dE/dx and range tables from 100 eV to 100 TeV in 84 bins
Lambda tables from threshold to 100 TeV, 7 bins per decade, spline: 1
finalRange(mm)= 1, dRoverRange= 0.2, integral: 1, fluct: 1, linLossLimit= 0.01
===== EM models for the G4Region DefaultRegionForTheWorld ======
MollerBhabha : Emin= 0 eV Emax= 100 TeV
eBrem: for e+ SubType= 3
dE/dx and range tables from 100 eV to 100 TeV in 84 bins
Lambda tables from threshold to 100 TeV, 7 bins per decade, spline: 1
LPM flag: 1 for E > 1 GeV, VertexHighEnergyTh(GeV)= 100000
===== EM models for the G4Region DefaultRegionForTheWorld ======
eBremSB : Emin= 0 eV Emax= 1 GeV DipBustGen
eBremLPM : Emin= 1 GeV Emax= 100 TeV DipBustGen
annihil: for e+, integral: 1 SubType= 5 BuildTable= 0
===== EM models for the G4Region DefaultRegionForTheWorld ======
eplus2gg : Emin= 0 eV Emax= 100 TeV
Aparecerá un nuevo fichero en el directorio de trabajo: simulation.wrl. Este fichero es un diagrama 3D que puedes ver con un visualizador externo.
wrl?La extensión de archivo
WRLse refiere a un archivo creado enVRML, que viene de Lenguaje de Modelado de Realidad Virtual. Este archivo, representa un mundo 3D virtual, es guardado con un formato de textoASCIIy puede ser editado por un editor de texto.
De
VRMLo Lenguaje de Modelado de Realidad Virtual (Siglas del inglés Virtual Reality Modeling Language)
Este comando que acabamos de comentar (docker run) crea un contenedor Docker que tiene mapeada la carpeta interna /root con el directorio personal (home) del usuario root. Esto se consigue con la opción -v (más info aquí). Sí… suena un poco mareante y efectivamente así es.
El contenedor anterior tiene como cometido ejecutar un único proceso (que no es otro que un intérprete Python que interpreta las instrucciones de simulation.py). Como las dos carpetas están enlazadas tanto para lectura como escritura, el fichero simulation.wrl estará disponible en /root.
Para entender el resto de opciones disponibles para la simulación, es recomendable que leas la guía que tienes disponible aquí. También puedes visitar la versión live en el sitio oficial de pruebas y formación de Docker.
Una vez que ya tenemos la simulación, sólo tenemos que visualizarla con Instant Player (o ParaView o view3dscene). Para ello, tenemos que abrir el fichero que, encontraremos en el directorio de trabajo, con Instant Player o, si ya está el fichero abierto, puedes simplemente recargarlo (File ➡️ Reload). Lo que vemos en el visualizador son trazas de partículas, es decir, sólo vemos partículas que estén en movimiento. Las partículas o materia paradas, no se muestran.
Pero quizás, la visualización más developer-friendly es la basada en HTML y estándares Web (WebGL). Luego ejecuta este comando para convertir el archivo .wrl a.html.
/usr/bin/python3 ./wrl2html.py
Esto generará el archivo simulation.html en tu carpeta de trabajo local.
Abre esta página web con cualquier navegador o directamente en VS Code con la extensión vscode-preview-server (comando Launch on browser) que has instalado al principio. Cada vez que se reescriba este fichero, la visualización se actualizará. En principio, la extensión preview-server debería actualizarla sin que digamos nada, pero si no lo hace, puedes guardar cualquier fichero (touch al directorio) y así debería actualizarse. También puedes simplemente indicarle al navegador (si estas usando un navegador externo) que refresque la página web.
Aquí podemos ver el resultado:
Vamos a describir las más habituales y que deberías de poder encontrar tú mismo en tus simulaciones. Tienes esta misma información, pero con algo más de detalle, en la versión live de este laboratorio.
El efecto fotoeléctrico se produce cuando tiene lugar una interacción entre un fotón (partícula incidente) y un átomo. La consecuencia de una interacción fotoeléctrica es la emisión de electrones (fotoelectrones), debido a la absorción total de la energía del fotón por el electrón ligado. El fotón es absorbido completamente y desaparece de la escena.
El efecto Compton tiene lugar en la interacción de un fotón (partícula incidente) y un electrón poco ligado al átomo. Se produce entonces una colisión casi elástica. Al colisionar el fotón con el electrón este es desviado, y el fotón original también. Puede asemejarse a un choque de bolas de billar. A veces si la energía del fotón incidente es muy justa, el electrón (o electrones, en el caso de una colisión múltiple) desviado apenas avanza (su traza es muy pequeña, casi imperceptible) y da la sensación de que el fotón (que, recordamos, no es más que luz) está zigzagueando.
170.000 años + 8 minutos
La Tierra se encuentra a casi 150 millones de kilómetros del Sol. Distancia que tarda en recorrer algo más de ocho minutos. Pero la respuesta en realidad es bastante más compleja, puesto que el nucleo del sol es extremadamente denso, unas diez veces más que el plomo y su temperatura es tan alta que el hidrógeno se encuentra en forma de plasma, es decir, los electrones y los protones no se encuentran ligados en un átomo, sino que ‘campan a sus anchas’ formando una sopa de partículas cargadas eléctricamente.
Para conseguir salir del sol tienen que recorrer unos 690.000 kilómetros plagados de trillones de protones que se interponen en su camino propiciando que se den cualquiera de los efectos que se reproducen en la simulación. Cualquiera de ellos hará que el fotón rebote en direcciones aleatorias. Si se tiene en cuenta la cantidad de protones, su separación en las distintas capas del Sol y la distancia total que tienen que recorrer, los últimos modelos matemáticos arrojan un resultado final aproximado de ¡170.000 años hasta que los fotones alcanzan la superficie!
Fuente: https://terceravia.mx/
El efecto de creación de pares tiene lugar con fotones de alta energía (> 1.1 MeV), y representa un proceso de materialización de energía en el sentido de la Mecánica Relativista. El fenómeno que tiene lugar es la desaparición del fotón en el campo del núcleo, y la creación en su lugar de un par positrón-electrón (materia y antimateria).
El positrón o antielectrón es una partícula elemental, antipartícula del electrón. Posee la misma cantidad de masa y espín que el electrón; sin embargo, su carga es de 1e, mientras que la del electrón es de -1e.
Si en los choques de una partícula cargada con los electrones atómicos, la energía transferida es superior a la energía de enlace del electrón que recibe el impacto, este abandona el átomo y en consecuencia se crea un ion positivo. El electrón expulsado puede a continuación zigzaguear hasta ser capturado por un átomo del entorno (la traza deja de verse porque, como hemos comentado, el electrón se para).
Cuando una partícula incidente con masa y carga eléctrica interacciona con un núcleo atómico, puede sufrir una variación súbita de su velocidad, emite radiación electromagnética (un fotón).
Si un positrón y un electrón se encuentran, se aniquilan creando dos fotones que son emitidos en direcciones opuestas.
La modalidad radiológica PET (de las siglas en inglés de Positron Emission Tomography) o Tomografía por Emisión de Positrones, es una exploración no invasiva de diagnóstico por imagen que es capaz de medir la actividad metabólica del cuerpo humano. La PET se basa en detectar y analizar la distribución en tres dimensiones que adopta en el interior del cuerpo un radiofármaco de vida media ultracorta administrado a través de una inyección intravenosa.
La obtención de imágenes PET se basa en la detección de la radiación emitida por el Radioisótopo inyectado en el paciente. Estos radioisótopos son isótopos de un elemento químico con una configuración nuclear inestable que emite radiación al decaer a una forma estable en un proceso que se conoce como decaimiento radioactivo.
El Decaimiento provoca la emisión de partículas a partir del núcleo inestable, el cual pierde energía. Esto sucede debido a la inestabilidad del átomo que trata de encontrar configuración más estable, a base de modificar la relación de protones y neutrones en el núcleo atómico. Cuando esto sucede se emite radiación que puede ser principalmente de tres tipos: emisión de partículas α, emisión de partículas β o radiación γ.
Es la emisión de partículas β la que interés, puesto que a medida que el radioisótopo emisor de radiación β+ inyectado en el paciente se desintegra, emite positrones. Cada uno de estos puede colisionar con un electrón cortical del tejido en el que está presente el radiofármaco. Esta aniquilación da lugar fundamentalmente a la emisión de dos rayos gamma de en la misma dirección y sentidos opuestos, es decir, provocan una aniquilación de pares.
A través de un isotopo radiactivo inyectado al paciente. Existen varios radiofármacos emisores de positrones de utilidad médica. El más importante de ellos es el radiotrazador llamado Fluorodesoxiglucosa (18FDG). Gracias a él tendremos la posibilidad de poder identificar, localizar y cuantificar, a través de un indicador conocido como SUV (Standardized Uptake Value) el consumo de glucosa en los diferentes tejidos. La utilización de este radiotrazador 18FDG en los procesos neoplásicos está basado en el hecho de que en el interior de las células tumorales se produce un metabolismo fundamentalmente anaerobio que incrementa la expresión de las moléculas transportadoras de glucosa. La 18FDG sí es captada por las células pero al no poder ser metabolizada, sufre un “atrapamiento metabólico” gracias al cual se obtienen las imágenes con las captaciones de esos tejidos.
Se pide un informe técnico personal, elegante y bien presentado de todas las tareas necesarias para la ejecución de la actividad. Es decir, reproducid en vuestro escenario todos los pasos realizados y que más o menos imiten a los que ya vienen descritos en este documento (instalación de software, configuración, accesos remotos, etc.).
Contestad a todas las preguntas intermedias que se proponen.
Buscad e identificad todos los tipos de interacciones de partículas con la materia posibles, modificando para ello todos los parámetros de la simulación. Comenta claramente el setup experimental definido en cada caso (energía de las partículas, si se trata de fotones, electrones o positrones, posición del haz, tipo de fantoma, material del mismo, etc.). Ejemplifica cada interacción con un captura de pantalla bien explicada del fenómeno físico que se pueda apreciar. A continuación tienes un resumen de las interacciones más básicas a estas energías.
El documento final debe tener formato PDF o HTML inline (todos los recursos incrustados en único fichero). Para generar el HTML inline puedes exportar primero a HTML desde Typora (esto creará un fichero HTML y un subdirectorio con todas las imágenes que hayas incluido en tu fichero original Markdown) y luego condensar todos los recursos en un único documento. Para llevar a cabo esta labor de condensación tienes a tu disposición varias herramientas basadas en Node.js/npm. Las mejores son inline assets y monolith (esta última no requiere Node) con las que podrás fusionar todos los recursos de una web en un único documento HTML
Antes de ponernos a hacer las simulaciones vamos a analizar un poco el código Python del archivo simulation.py que es el que se encarga de ejecutar la simulación.
Lo primero que no encontramos es todas la importaciones de librerías necesarias.
import Geant4
from Geant4 import *
import g4py.NISTmaterials
import g4py.ezgeom
from g4py.ezgeom import G4EzVolume
import g4py.EMSTDpl
import g4py.ParticleGun
import g4py.MedicalBeam
import os.path
import sys
import getopt
Seguido encontramos la inicialización de variables de las que hace uso la simulación. Se observa que se inicializan a unos valores por defecto y después se sobrescriben estos valores en el caso de recibir algún parámetro por línea de comandos.
particle_type = "gamma"
particle_count = 20
particle_energy = 1
phantom_thickness = 20
material = "G4_WATER"
wrl_file = "simulation.wrl"
opts, args = getopt.getopt(sys.argv[1:], '', ['type=', 'count=', 'energy=', 'size=', 'material=', 'wrl='])
for opt, arg in opts:
if opt in ('--type'):
particle_type = arg
elif opt in ('--count'):
particle_count = int(arg)
elif opt in ('--energy'):
particle_energy = float(arg)
elif opt in ('--size'):
phantom_thickness = int(arg)
elif opt in ('--material'):
material = arg
elif opt in ('--wrl'):
wrl_file = arg
De aquí ya podemos extraer varias cosas que nos pueden ser útiles para realizar las simulaciones, como son los nombres de las variables que contienen los parámetros que se usaran durante las simulaciones. Tomemos nota de ellos:
particle_type: Tipo de partícula emitidaparticle_count: Numero de partículas emitidasparticle_energy: Energía de partida de las partículas emitidasphantom_thickness: Grosor del Targetmaterial: Material del Targetwrl_file: Nombre del fichero de salidaPero en realidad lo que a nosotros no interesa son los nombres de los argumento que se usan para dar valor a cada una de esas variables:
type: Tipo de partícula emitidacount: Numero de partículas emitidasenergy: Energía de partida de las partículas emitidassize: Grosor del Targetmaterial: Material del Targetwrl: Nombre del fichero de salida# Phantom material
electron_color = "red"
positron_color = "yellow"
photon_color = "white"
rand_engine = Ranlux64Engine()
HepRandom.setTheEngine(rand_engine)
HepRandom.setTheSeed(20050830L)
g4py.NISTmaterials.Construct()
g4py.ezgeom.Construct()
g4py.EMSTDpl.Construct()
g4py.ParticleGun.Construct()
Aquí podemos ver que colores se van a usar para representar casa tipo de partícula. Tenemos rojo para el electrón, amarillo para el positrón y blanco para el fotón.
# World definition
emptiness = G4Material.GetMaterial("G4_Galactic")
g4py.ezgeom.SetWorldMaterial(emptiness)
g4py.ezgeom.ResizeWorld(121.*cm, 121.*cm, 400.*cm)
Aquí se ha definido el espacio en el que se contendrá el experimento.
Vemos que será un ortoedro de x x de un espacio vacío.
# Phantom definition
phantom_material = G4Material.GetMaterial(material)
phantom = G4EzVolume("PhantomBox")
phantom_zwidth = phantom_thickness*cm
phantom_zlocation = 100.*cm
phantom.CreateBoxVolume(phantom_material, 120.0 * cm, 120.0 * cm, phantom_zwidth)
phantom.SetColor(0., 0.9, 1.0)
phantom_box_pv = phantom.PlaceIt(G4ThreeVector(0.*cm, 0.*cm, phantom_zlocation))
Aquí vemos la definición del Target.
Se establece tanto el tamaño como el material del que estará formado, así como su posición.
No necesitamos nada de aquí, puesto que las variables que utiliza para configurar los parámetros que podríamos necesitar tocar ya las tenemos de antes. phantom_thickness y material
# Beam definition
beam = g4py.MedicalBeam.Construct()
beam.particle = particle_type
beam.kineticE = particle_energy*MeV
beam.sourcePosition = G4ThreeVector(0.*cm, 0.*cm, -90.*cm)
beam.fieldXY = [120.*cm, 120.*cm]
beam.SSD = 190.*cm
Aquí se ha definido en la fuente emisora de partículas, el único elemento que nos podría interesar de aquí (particle_energy) también lo tenemos de antes.
# Visualization commands
gApplyUICommand("/run/initialize")
gApplyUICommand("/vis/viewer/flush")
gApplyUICommand("/vis/open VRML2FILE")
gApplyUICommand("/vis/viewer/refresh")
gApplyUICommand("/vis/scene/create")
gApplyUICommand("/vis/scene/add/volume")
gApplyUICommand("/vis/drawVolume")
gApplyUICommand("/vis/modeling/trajectories/create/drawByParticleID")
gApplyUICommand("/vis/modeling/trajectories/drawByParticleID-0/set gamma " + photon_color)
gApplyUICommand("/vis/modeling/trajectories/drawByParticleID-0/set e- " + electron_color)
gApplyUICommand("/vis/modeling/trajectories/drawByParticleID-0/set e+ " + positron_color)
gApplyUICommand("/vis/sceneHandler/attach")
gApplyUICommand("/vis/viewer/set/style wireframe")
gApplyUICommand("/vis/viewer/set/viewpointThetaPhi 70. 10.")
gApplyUICommand("/vis/viewer/zoom 1.")
gApplyUICommand("/tracking/storeTrajectory 1")
gApplyUICommand("/vis/scene/add/trajectories")
gApplyUICommand("/vis/scene/add/hits")
gApplyUICommand("/vis/scene/add/trajectories smooth")
gApplyUICommand("/vis/scene/endOfEventAction accumulate")
Aquí se ha definido la interfaz gráfica. Vemos que se establecen los diferentes colores que se usaran para cada tipo de partícula. También hay algunos parámetros interesantes relativos a la vista, como el zoom o el estilo wireframe, que seguramente no necesitaremos tocar.
# Run simulation
gRunManager.Initialize()
gRunManager.BeamOn(particle_count)
os.rename("g4_00.wrl", wrl_file)
Por último se ejecuta la simulación.
Nosotros para ejecutar la simulación lo debemos de hacer por medio de Docker con el siguiente formato de comando:
docker run -v ${PWD}:/root pammacdotnet/g4lpwd [--type=] [--count=] [--energy=] [--size=] [--material=] [--wrl=]
Como hemos dicho antes, el efecto fotoeléctrico se produce cuando tiene lugar una interacción entre un fotón y un átomo. La consecuencia de una interacción fotoeléctrica es la emisión de electrones, debido a la absorción total de la energía del fotón por el electrón ligado. El fotón es absorbido completamente y desaparece de la escena.
Para provocar este evento cambiaremos algunos de los parámetros por defecto en la simulación. En este caso utilizaremos una energía de , que equivalen a
Para simular el Efecto fotoeléctrico casi no cambiaremos los parámetros por defecto. Usaremos el comando de esta forma:
docker run -v ${PWD}:/root pammacdotnet/g4lpwd --energy=0.05
Con esto habremos generado el archivo simulation.wrl.
Generamos el .html y lo movemos a la carpeta Simulaciones con el nombre simulacion_efecto_fotoeléctrico.html
/usr/bin/python3 wrl2html.py
mv simulation.html ./Simulaciones/simulacion_efecto_fotoeléctrico.html
Si buscamos por la representación en 3D de la simulación podemos encontrar el evento de la imagen.
Haciendo muchísimo zoom se puede observar en la imagen como el fotón desprende un electrón de un átomo, aunque este es enseguida absorbido.
Simulación:
El efecto Compton tiene lugar en la interacción de un fotón y un electrón poco ligado al átomo. Al colisionar el fotón con el electrón este es desviado, y el fotón original también. A veces, si la energía del fotón incidente es muy justa, el electrón desviado apenas avanza y da la sensación de que el fotón está zigzagueando.
Para provocar este evento cambiaremos algunos de los parámetros por defecto en la simulación. En este caso utilizaremos una energía de , que equivalen a
docker run -v ${PWD}:/root pammacdotnet/g4lpwd --energy=0.5
Con esto habremos generado el archivo simulation.wrl.
Generamos el .html y lo movemos a la carpeta Simulaciones con el nombre simulacion_efecto_compton.html
/usr/bin/python3 wrl2html.py
mv simulation.html ./Simulaciones/simulacion_efecto_compton.html
Si buscamos por la representación en 3D de la simulación podemos encontrar el evento de la imagen.
Aquí podemos observar un efecto similar al efecto fotoeléctrico, aquí el fotón colisiona con el electrón y lo expulsa del átomo, pero el fotón sigue manteniendo suficiente energía para continuar desviándose de su trayectoria.
Simulación:
El efecto de creación de pares tiene lugar con fotones de alta energía. El fotón desaparece y se crea un par positrón-electrón.
Para provocar este evento cambiaremos algunos de los parámetros por defecto en la simulación. En este caso utilizaremos una energía de , que equivalen a
docker run -v ${PWD}:/root pammacdotnet/g4lpwd --energy=20
Con esto habremos generado el archivo simulation.wrl.
Generamos el .html y lo movemos a la carpeta Simulaciones con el nombre simulacion_producción_de_pares.html
/usr/bin/python3 wrl2html.py
mv simulation.html ./Simulaciones/simulacion_producción_de_pares.html
Si buscamos por la representación en 3D de la simulación podemos encontrar el evento de la imagen.
En la imagen se aprecia como el fotón colisiona y eyecta un par electrón y positrón.
Simulación:
Si en los choques de una partícula cargada con los electrones atómicos, la energía transferida es superior a la energía de enlace del electrón que recibe el impacto, este escapa del átomo, por lo que el átomo queda con un electrón menos y se convierte en un ion positivo.
Para provocar este evento cambiaremos algunos de los parámetros por defecto en la simulación. Para propiciar este evento en vez de fotones emitiremos electrones con una energía de , que equivalen a
docker run -v ${PWD}:/root pammacdotnet/g4lpwd --type=e- --energy=20
Con esto habremos generado el archivo simulation.wrl.
Generamos el .html y lo movemos a la carpeta Simulaciones con el nombre simulacion_ionización.html
/usr/bin/python3 wrl2html.py
mv simulation.html ./Simulaciones/simulacion_ionización.html
Si buscamos por la representación en 3D de la simulación podemos encontrar el evento de la imagen.
En la imagen se observa com al interactuar el electrón con otro electrón, consigue que el segundo se desprenda de su átomo y salga proyectado.
En el caso de la imagen es un electrón el provoca el evento, pero esto también puede provocarlo un fotón o un positrón. De hecho, el efecto fotoeléctrico y el efecto Compton son dos casos particulares de ionización, en ambos se desprende un electrón de un átomo haciendo que este quede en forma de ion positivo.
Simulación:
Cuando una partícula incidente con masa y carga eléctrica interacciona con un núcleo atómico, puede sufrir una variación súbita de su velocidad, emite radiación electromagnética (un fotón).
Para provocar este evento cambiaremos algunos de los parámetros por defecto en la simulación. Para propiciar este evento en vez de fotones emitiremos electrones con una energía de , que equivalen a
docker run -v ${PWD}:/root pammacdotnet/g4lpwd --type=e- --energy=20
Con esto habremos generado el archivo simulation.wrl.
Generamos el .html y lo movemos a la carpeta Simulaciones con el nombre simulacion_bremsstrahlung.html
/usr/bin/python3 wrl2html.py
mv simulation.html ./Simulaciones/simulacion_bremsstrahlung.html
Si buscamos por la representación en 3D de la simulación podemos encontrar el evento de la imagen.
En la image se ve como un electrón es frenado, perdiendo energía en forma de un fotón emitido en la dirección de frenado.
Simulación:
Si un positrón y un electrón se encuentran, se aniquilan creando dos fotones que son emitidos en direcciones opuestas.
Para provocar este evento cambiaremos algunos de los parámetros por defecto en la simulación. En este caso utilizaremos una energía de , que equivalen a
docker run -v ${PWD}:/root pammacdotnet/g4lpwd --energy=20
Con esto habremos generado el archivo simulation.wrl.
Generamos el .html y lo movemos a la carpeta Simulaciones con el nombre simulacion_aniquilación_de_pares.html
/usr/bin/python3 wrl2html.py
mv simulation.html ./Simulaciones/simulacion_aniquilación_de_pares.html
Si buscamos por la representación en 3D de la simulación podemos encontrar el evento de la imagen.
Simulación:
En la imagen se observa como un positrón, llegado un punto desaparece, y de ese punto salen emitidos dos fotones en sentidos opuestos. Esto es debido a que el positrón a colisionado con un electrón y, partícula y antipartícula se aniquilan eyectando energía en sentidos opuestos en forma de fotones.